text-embedding-3 de OpenAI: qué cambia respecto al anterior

OpenAI liberó text-embedding-3 el 25 de enero de 2024, en dos variantes: text-embedding-3-small (más barato, 1536 dim) y text-embedding-3-large (calidad superior, 3072 dim). Es el primer cambio mayor en embeddings OpenAI desde text-embedding-ada-002 (diciembre 2022). Para equipos que construyen RAG sobre OpenAI, la pregunta inmediata es: ¿migrar? Y si sí, ¿cuándo? Este artículo cubre qué aporta, cómo comparar, y estrategias para el cambio.

Qué hay de nuevo

Cinco cambios concretos respecto a ada-002:

• Calidad MTEB (benchmark multi-tarea): text-embedding-3-large saca ~64% (vs 61% de ada-002). 3-small saca ~62%.
• Dimensiones variables: puedes truncar las embeddings a menos dimensiones sin reentrenar. 3072 → 512 mantiene ~80% de calidad con un tercio del almacenamiento.
• Multilingüe mejorado: 3-large en MIRACL (benchmark multilingüe) sube de 31% a 54% vs ada-002.
• Precio menor para small: $0.02 / 1M tokens (vs $0.10 de ada-002). large es $0.13 / 1M.
• Mejor manejo de longitud: contexto máximo sigue en 8191 tokens, pero mejora en documentos largos.

El combo “más barato + mejor calidad” es raro; normalmente hay que pagar uno con el otro.

Dimensiones variables: cómo funciona

La técnica se llama Matryoshka Representation Learning — el modelo está entrenado para que los primeros N componentes del vector sean una representación funcional por sí mismos.

Práctica:

from openai import OpenAI
client = OpenAI()

# Generar embedding completo
res = client.embeddings.create(
    input="Texto de ejemplo",
    model="text-embedding-3-small",
    dimensions=512  # <— opcionalmente truncar desde el servidor
)
# O bien truncar del lado cliente
full = res.data[0].embedding
truncated = full[:512]

Truncar permite:

• Índices más pequeños: 3x menos memoria en pgvector/Qdrant/Pinecone.
• Búsquedas más rápidas: menos dimensiones = menor cómputo por query.
• A/B testing fácil: probar 256 vs 512 vs 1536 sin reindexar todo.

Regla práctica: para ES/EN RAG, 512 dim es buen punto intermedio. Para multilingüe complejo, 1024 dim.

Migración desde ada-002

El cambio no es plug-and-play si ya tienes embeddings indexados. Opciones:

• Reindexar todo: reprocesar tu corpus con el nuevo modelo. Coste: proporcional al tamaño. Para 10M docs de 1KB cada uno, ~10B tokens × $0.02/M = $200 con 3-small.
• Migración gradual: mantener ada-002 para docs existentes, usar 3-small para nuevos, con índices separados y búsqueda sobre ambos. Complica.
• Hybrid search: embeddings nuevos y viejos coexisten por un tiempo, con un re-rank final unificado.

Para la mayoría, reindexar de golpe es más limpio. El coste es manejable y la ganancia de calidad compensa.

Comparación con alternativas open source

Donde queda frente a embeddings abiertos en MTEB:

BGE-large y E5-large son casi par con OpenAI en calidad, pero requieren infraestructura propia. El trade-off es clásico: OpenAI es simple pero dependencia externa; self-hosted es control pero ops.

Consideraciones de latencia

OpenAI embedding API: ~50-200ms p50, puede llegar a 1s+ en picos. Para batch processing no importa; para queries en tiempo real puede ser problemático.

Alternativas:

• Cache agresivo: las queries similares pueden reutilizar embeddings cacheados.
• Modelo local para la query (rápido) + índice con OpenAI embeddings para docs (se precomputaron offline). Conceptualmente distinto pero funciona si escoges bien el modelo local.
• Batch embeddings: OpenAI acepta hasta 2048 inputs por llamada — amortizar la latencia.

Residencia de datos

OpenAI procesa en US por defecto. Para compliance europeo:

• Azure OpenAI ofrece regiones EU (West Europe, etc).
• text-embedding-3 disponible en Azure con mismo SLA.
• Precios similares.

Para empresas europeas reguladas, Azure es la vía; para el resto, OpenAI directo suele ser más ágil.

Cuándo migrar

Criterios claros:

Migrar ya:

• Recall o precisión son bottleneck de tu RAG.
• Corpus multilingüe (ganancia mayor en MIRACL).
• Volumen alto en ada-002 donde ahorras con 3-small.

Esperar:

• RAG funciona bien, métricas estables.
• Cambios inminentes en tu producto que harán reindexar obligatorio de todos modos.
• Volumen bajo donde el coste de reindexar no se recupera pronto.

Ejemplo de benchmark propio

No te fíes solo de MTEB. Haz benchmark con tu corpus real:

# Golden set: 500 query-docRelevant pairs curados manualmente
for q, expected_doc in golden_set:
    # Ada-002
    old_emb = client.embeddings.create(input=q, model="text-embedding-ada-002")
    old_results = search(old_emb, index_ada)
    old_hits.append(expected_doc in old_results[:10])

    # Embedding-3
    new_emb = client.embeddings.create(input=q, model="text-embedding-3-small")
    new_results = search(new_emb, index_new)
    new_hits.append(expected_doc in new_results[:10])

print(f"ada: {sum(old_hits)/len(old_hits)*100:.1f}%")
print(f"new: {sum(new_hits)/len(new_hits)*100:.1f}%")

500 pares bien seleccionados son más informativos que millones de benchmarks públicos.

Errores comunes

Lo que hemos visto romper:

• Olvidar normalizar: distancia coseno vs producto interno no siempre son intercambiables. OpenAI normaliza, pero doblar por accidente causa problemas.
• Mezclar modelos en el mismo índice: buscar embeddings de distintos modelos en el mismo índice da basura.
• Dimensiones mal truncadas: truncar a [1:N+1] en vez de [:N]. Off-by-one mata calidad.
• No medir recall real post-migración. Solo medir “la API responde”.

Conclusión

text-embedding-3 es una mejora real y mensurable sobre ada-002. La opción de dimensiones variables es especialmente interesante por el impacto operativo — menor memoria, queries más rápidas. La migración merece la pena para la mayoría de casos RAG serios, aunque hay que presupuestar el reindexing. Para equipos con corpus multilingüe, la mejora en MIRACL es particularmente relevante. Frente a alternativas open source, la decisión sigue siendo la clásica entre simplicidad managed vs control self-hosted.

Síguenos en jacar.es para más sobre embeddings, RAG y estrategias de migración de modelos.